Hi All,
I have a script that is looking back through history records to produce a snapshot of what all the objects in the current document looked like on a specified date. I am finding history records for “Modify Object Attribute: Object Heading” where the .newValue of the history record is “(Default Value)”. This appears to indicate the value of the “Object Heading” was reset back to the empty string default value. The objects with these history records do not display any Object Heading text. I can also confirm the Object Heading attribute value is the empty string by looking on the “Attributes” tab of the properties dialog.
I can modify an object by changing the value of the Object Heading attribute to the string “(Default Value)”. This object will display an object heading of “(Default Value)”.
I can’t create new history records where the .newValue is set to “(Default Value)” while the attribute’s value is set to the empty string. I have even tried to do this using the properties dialog-->Attributes-->Edit/View-->Reset to Default. I’m wondering if this is behavior of older versions of DOORS.
For both of these cases the history record looks identical to me. Is there a way to determine which is which?
Thanks,
GothSloth
GothSloth - Fri Jul 20 19:08:03 EDT 2012 |
|
Re: History Record .newValue contains (Default Value), is it real?
Mathias Mamsch - Wed Aug 01 18:03:08 EDT 2012
Looking at the perms list I see that newValue returns a HAValue_ type and that type only has assignment operators for int, string etc. declared. So it seems you cannot differentiate between. I guess the history.dtc will also store that string literally. However it should not be a big practical problem. The string (default value) should not be so common in DOORS modules. Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: History Record .newValue contains (Default Value), is it real?
GothSloth - Fri Aug 03 14:44:23 EDT 2012
Mathias,
Thank you for your conformation on this. I'll have to add some special case logic to the script to handle the case. I do agree it should not be a common phrase in a document. I was hopping to avoid having extra script "features" to document and test for a formal tool.
Thanks,
GothSloth
|
|